1. Field of the Invention
This invention relates to memory management, and in particular relates to memory management in an operating system utilizing garbage collection to recover allocated memory.
2. Description of the Related Art
Many programming environments allow the user to specifically allocate memory to objects, and have the environment automatically recover that memory when the objects are no longer referenced. For example, in a Java virtual machine, the user creates an object that references memory allocated to the object in a memory heap. A garbage collector scans the heap and removes the allocated memory, making that memory available again, after the object is no longer needed by the user. However, if the object is not removed but never accessed again, the memory remains allocated during the application life span—resulting in a memory “leak.”
Most Java implementations restrict applications to a fixed memory heap size—typically 2 GB in a 32-bit application running on a virtual machine (with a 4 GB theoretical limit)—placing pressure on developers to minimize usage of the heap. Some Java implementations may allow significantly larger memory heap sizes. However, presently available heap management techniques drive the system to require equivalent physical random access memory (RAM) to the heap size if sufficient performance is to be maintained. Therefore, if an extremely large heap is required, the hardware costs can be significant. Further, garbage collection cycles of large memory heaps can be slow even when appropriate RAM is available. Although Java is the most popular and well known garbage collecting memory management environment, other garbage-collecting languages (e.g. Lisp, C#, etc.) have similar limitations.